https://app.devrev.ai/devrev/works/ISS-219002

This PR adds support for resolving array fields which was not added before.

Note: We are going to get array fields only in a table visualization. It is not going to come in any other visualization.

In the resolution config, added a new field isArrayType which indicates if the field is an array type or not. If there is atleast one array resolution field, we go through a new flow using the below steps

1. Use the original query with all the filters, sort etc.,
2. Perform unnest for all the array columns and add row_id column to identify the row_id, so that, if there is a column with 4 items in the array, because of unnest, we will have 4 rows, but since we also have row_id, it will be the same and can be used for aggregating. For unnest, we have a sql modifier which we use and in that sql, we use [null] if the value of that column is empty or null, so that, one row is getting produced. If there are 0 rows, unnest will result in 0 rows.
3. Perform join of this unnested field with the resolution tables and get the resolved fields
4. With the previous step, we have all the resolution and now, we need to aggregate columns based on row_id and for any columns which was not resolved, we can take min/max, and rest of the columns, we need to do array_Aggregate and distinct

What is not guaranteed:

1. If we have multiple items in the same column in the array, it is not guaranteed to have the resolved values also in the same order

What is guaranteed:

1. All filters and orders are maintained
2. All fields for which we have the resolutions are being resolved, whether a value needs to be resolved to 1 column or n columns
3. Having the same order as column projections. In devrev-web, we use hidden and order to get the correct order for columnProjections ( This happens only when we have table visualization )

Test Cases Verified:

1. Even if no resolution/single resolution or multiple resolution is there, verified that we have the same ordering of column order as presentin the widget.
2. Verified using test cases, that, if there is a sort, we are using it properly, but right now, there are some issues in the UI, resulting in overrided sorted fields, which team needs to look into